home *** CD-ROM | disk | FTP | other *** search
-
- T H E G A M E S M A S T E R S Y S T E M
-
-
- A N I N T R O D U C T I O N
-
-
-
- This introductory text is taken directly from the web pages:
-
- http://www.compkarori.co.nz/amiga/gameslib/
-
-
-
-
- WHAT IS THE GAMES.LIBRARY?
-
-
- The Games.Library is a solution to one of the biggest problems the Amiga
- community has faced. As high end machines move over to graphics cards, how
- do we maintain compatibility between all the different hardware... we were
- bad enough when we just had OCS and ECS!! There have been mentions of
- libraries specifically tailored to handling graphics cards, but these are
- missing the big picture.
-
- The Big Picture
-
- Hardware bashing is fast, sometimes many times as fast as an equivalent
- system legal routine. However hardware bashing is not very compatible with
- other hardware types, resulting in unpredictable results on other systems.
- No programmer can be expected to support dozens of obscure hardware
- configurations... just look at what it did to the PC, you can't install a
- game without going through and setting IRQs for sound cards. Let's face
- it, if the problem isn't dealt with directly, then the situation is just
- going to get worse as new hardware is released.
-
- But how are *we* going to deal with this ever increasing problem? No-one
- has ever come up with an acceptable solution for our little Amiga. Maybe
- we are getting close to retargettable graphics, but what about
- retargettable sound? What about user support? What about networking?
- Where's our support for all those different joysticks? Where's the real
- support for writing games in an OS? What about all the other stuff people
- keep moaning about? Well after a lot of design and investigation into
- this, a solution is already on its way. A clever system that uses some
- simple common sense and technical know-how has evolved into what has now
- been dubbed as...
-
- THE GAMES MASTER SYSTEM
-
-
- The "Games Master System" solves all the problems developers have faced in
- the past, and are still facing today. Project GMS encompasses not only the
- games.library but also all the GPI's, documentation, developer information,
- and most importantly the user prefences program (GMS Prefs). All these
- things have been designed to work together and will achieve the following:
-
- * Erradication of the need to bash the hardware from within games.
- * Make it easier to migrate from the current Amigas to the new Power Amigas.
- * Make games programming, easier, faster, and more productive.
- * Give users the ability to modify any game to suit their requirements.
-
-
- How does it work?
-
-
- First lets look at the way games are written on the Amiga today. A lot of
- experienced coders would tell you that a lot of their source is automated,
- put into macros, drawing routines, sound routines, and so it goes on.
- Rather interestingly, this is usually the same stuff that is doing all the
- hardware hacking.
-
- By taking these commonly used routines and putting them into a library we
- remove the hardware compatibility problem immediately. Unfortunately for
- us, although it works this method is just not fast enough for the speed
- that games require. Enter the use of GPI's!
-
- A GPI (short for "Games Programming Interface") is a collection of library
- functions specifically designed to perform a task for just one hardware
- device. Each GPI can therefore be built to do whatever it wants without
- having to worry about compatibility problems. New versions of an existing
- GPI can be written for different hardware devices, so graphics cards, sound
- cards, 3D chips etc can be supported.
-
- The benefit of this is that the user gets the best possible speed, while
- the programmer can simply utilise the built-in routines and know that not
- only will their game be fast, but also be compatible with Amigas
- everywhere. Amazing!
-
- User Support
-
-
- If you're a games player then there have probably been a number of times
- where you've thought "Why can't I use my Sega Joypad?", "I want to run in a
- DBLPAL screen!", "I want multi-tasking!", "I want to turn the music off!",
- "I want, I want, I want!". Well that's what it sounds like to developers
- who don't have time to support all these things!
-
- Luckily an important feature of the Games Master System is the level of
- support given to the user. The GMS Prefs program allows the user to select
- levels of mode promotion, type of joystick used, vector detail, networking,
- C2P routines, music re-direction, task priorities, and much much more.
- This solves a lot of the moans and gripes that users have had in the past,
- and as this is all transparent to the programmer user support is easily
- achieved. Hopefully this news will make you all very happy!
-
-
- Anything else?
-
-
- Well that just about sums up the Games Master System rather well. Look
- around the rest of the site to get more detail on the things mentioned
- here, and other things that we haven't gone into yet. Remember to ask us
- if you have any questions about the project!
-
-
-
- ---------------------------------------------------------------------------
-
-
-
- GPI INFORMATION
-
-
-
- As you my have read in the Introduction, GPI's are the key components
- behind the games.library. In fact the only thing contained in the
- games.library are some standard system functions. Otherwise the library
- just serves as a "skeleton" of function calls, rather than having the code
- residing within the library itself. The library is "filled out" on opening
- by loading the GPI's from disk, with each GPI consisting of a group of
- function calls pertaining to one particular area of games programming. For
- example, the Screens.GPI contains routines for opening and closing a
- screen, altering the screen's palette, placing sprites onto a screen, etc.
- Other GPI's are purely optional, and must be initialised before use, e.g
- the Vectors.GPI. This saves a lot of memory as you only have to load in
- what you need.
-
- Only three GPI's are loaded as standard (these are considered essential
- game components), and they are:
-
- Screens.GPI
- Blitter.GPI
- Sound.GPI
-
- Each GPI is written for one particular hardware device only. Currently the
- Screens, Blitter and Sound GPI's are being written for OCS/ECS/AGA
- machines, and when their functions are finalised new GPI's for other
- hardware devices can then be written. Anyone is allowed to write a GPI for
- a hardware device so long as they obtain our permission first (so we can
- keep track of who is doing what). Write to us if you're interested!
-
- You might also be wondering what other GPI's are planned. The current list
- stands as follows:
-
- Network.GPI
- Vectors.GPI
- C2P GPI(s)
-
- We are looking for people to help write or donate routines that could be
- used in the construction of these GPI's. We don't have the time to do all
- of this ourselves with the amount of work to be done on the rest of the
- project! If you make a significant enough contribution to a GPI's
- development, you get full registered developer privileges to this project,
- for *life*. Mail Paul right away if you can help.
-
-